Apparatus and method for optimized multi-format communication delivery protocol prediction

ABSTRACT

This disclosure relates generally to apparatus, methods, and computer readable media for composing communications for computing devices across multiple formats and multiple protocols. More particularly, but not by way of limitation, this disclosure relates to apparatus, methods, and computer readable media to permit computing devices, e.g., smartphones, tablets, laptops, and the like, to send communications in a number of pre-determined and/or ‘determined-on-the-fly’ optimal communications formats and/or protocols. Determinations of optimal delivery methods may be intelligently based on the sender individually or the relationship with the sender in the context of a group of recipients—including the format of the incoming communication, the preferred format of the recipient and/or sender, and an optimal format for a given communication message. The techniques disclosed herein allow communications systems to become ‘message-centric’ or ‘people-centric,’ as opposed to ‘protocol-centric,’ eventually allowing consideration of message protocol to fall away entirely for the sender of the communication.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of the commonly-assigned patentapplication having U.S. patent application Ser. No. 14/985,721 filedDec. 31, 2015, and entitled, “Apparatus and Method for OptimizedMulti-Format Communication Delivery Protocol Prediction,” (“the '721application”), which is a continuation-in-part of the commonly-assignednonprovisional patent application having U.S. patent application Ser.No. 14/141,551 filed Dec. 27, 2013, and entitled, “Apparatus and Methodfor Multi-Format Communication Composition” (“the '551 application”).The '551 application and the '721 application are also herebyincorporated by reference in their entireties.

TECHNICAL FIELD

This disclosure relates generally to apparatuses, methods, and computerreadable media for composing communications for computing devices acrossmultiple communications formats and protocols as intelligentlydetermined using one or more context factors to determine the optimaldelivery method for the communications.

BACKGROUND

The proliferation of personal computing devices in recent years,especially mobile personal computing devices, combined with a growth inthe number of widely-used communications formats (e.g., text, voice,video, image) and protocols (e.g., SMTP, IMAP/POP, SMS/MMS, XMPP, etc.)has led to a communications experience that many users find fragmentedand restrictive. Users desire a system that will provide ease ofcommunication by sending an outgoing message created in whatever formatwas convenient to the composer, with delivery options to one or morereceivers in whatever format or protocol that works best for them—allseamlessly from the composer's and recipient(s)'s perspective. Withcurrent communications technologies that remain “protocol-centric”—asopposed to “message-centric” or “people-centric”—such ease ofcommunication is not possible.

In the past, users of communications systems first had to choose acommunication format and activate a corresponding application or systemprior to composing a message or selecting desired recipient(s). Forexample, if a person wanted to call someone, then he or she would needto pick up a telephone and enter the required phone number or directoryin order to connect. If a person wanted to email a colleague, thatperson would be required to launch an email application before composingand sending the email. Further, while long-form text might be the mostconvenient format at the time for the composer, long-form text may notbe convenient for the receiver—resulting in a delayed receipt of and/orresponse to the message by the receiver. With the multi-formatcommunication composition techniques described herein, however, the userflow is much more natural and intuitive. First, the ‘Sender’ (e.g., aregistered user of the multi-format, multi-protocol communicationsystem), can select the desired recipient(s). Then, the Sender maycompose the outgoing message (in any format, such as text, videorecording, or audio recording). Next, the system (or the Sender, in someembodiments) intelligently chooses the delivery protocol for thecommunication, e.g., whether the communication is going to be sent viaemail, SMS, IM, or social media, etc. Finally, the outgoing message isconverted into the desired outgoing message format (either by theSender's client device or a central communications system server) andsent to the desired recipient(s) via the chosen delivery protocol(s).

According to the multi-format communication composition techniquesdescribed herein, the emphasis in the communication interface is on the“who” and the “what” of the communication—but not the “how.” Themulti-format communication composition system described herein takescare of the “how”—including an ‘Optimal’ option, as determined by adedicated service in the central communication server, such as a servicereferred to herein as the ‘Optimal Decision Engine,’ which may beemployed to deliver the outgoing communication to the desiredrecipient(s) in the most preferred way, e.g., either through preferencesthat the recipient(s) has specified via his or her profile in amulti-format communications network or through the communicationprotocol information regarding the desired recipient that is stored inthe Sender's contact list.

The subject matter of the present disclosure is directed to overcoming,or at least reducing the effects of, one or more of the problems setforth above. To address these and other issues, techniques that enableseamless, multi-format communications via a single user interface aredescribed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating a server-entry point networkarchitecture infrastructure, according to one or more disclosedembodiments.

FIG. 1B is a block diagram illustrating a client-entry point networkarchitecture infrastructure, according to one or more disclosedembodiments.

FIG. 2A is a block diagram illustrating a computer which could be usedto execute the multi-format/multi-protocol communication optimizationapproaches described herein according to one or more of disclosedembodiments.

FIG. 2B is a block diagram illustrating a processor core, which mayreside on a computer according to one or more of disclosed embodiments.

FIG. 3A shows an example of a multi-protocol, people-centric,multi-format inbox feed, according to one or more disclosed embodiments.

FIG. 3B shows an example of a multi-protocol, multi-format inbox feedfor messages to and from a particular user, according to one or moredisclosed embodiments.

FIG. 3C shows an example of a preview pane for a multi-protocol,multi-format inbox feed for messages to and from a particular user,according to one or more disclosed embodiments.

FIG. 3D shows an example of a document repository page for a particularuser, according to one or more disclosed embodiments.

FIG. 3E shows an example of a multi-protocol, multi-format communicationcomposition user interface, according to one or more disclosedembodiments.

FIG. 4 is a flowchart of one embodiment of a method for populating amulti-protocol, people-centric, multi-format inbox feed, according toone or more disclosed embodiments.

FIG. 5 is a flowchart of one embodiment of a method for processing auser interface-driven query, according to one or more disclosedembodiments.

FIG. 6 is a flowchart of one embodiment of a method for creating amulti-protocol, multi-format communication transmission, according toone or more disclosed embodiments.

FIG. 7 is a block diagram of one embodiment of a Universal MessageObject, according to one or more disclosed embodiments.

FIG. 8 is a sequence diagram of one embodiment of a method for updatinga system with data points used to determine optimal delivery selection,according to one or more disclosed embodiments.

FIG. 9 is a flowchart of one embodiment of a method for determining anoptimal protocol for transmitting a message to a recipient, according toone or more disclosed embodiments.

DETAILED DESCRIPTION

Disclosed are apparatuses, methods, and computer readable media forcomposing communications for computing devices across multiple formatsand multiple protocols. More particularly, but not by way of limitation,this disclosure relates to apparatuses, methods, and computer readablemedia to permit computing devices, e.g., smartphones, smart devices,tablets, wearable devices, laptops, and the like, to send communicationsin a number of pre-determined and/or ‘determined-on-the-fly’communications formats and/or protocols via a single, seamless userinterface.

Determinations of outgoing communication formats and/or protocols may bebased on, e.g., the format of the incoming communication, the preferredformat of the recipient and/or sender of the communication, an optimalformat for a given communication session/message, and/or economicconsiderations of format/protocol choice to the recipient and/or sender(e.g. awareness of paid SMS internationally). The techniques disclosedherein allow communications systems to become ‘message-centric’ and/or‘people-centric,’ as opposed to ‘protocol-first,’ eventually allowingconsideration of message protocol to fall away entirely for the senderof the communication. With reference to the figures, embodiments ofcommunication optimization schemes according to this disclosure areprovided below.

Referring now to FIG. 1A, a server-entry point network architectureinfrastructure 100 is shown schematically. Infrastructure 100 containscomputer networks 101. Computer networks 101 include many differenttypes of computer networks available today, such as the Internet, acorporate network, or a Local Area Network (LAN). Each of these networkscan contain wired or wireless devices and operate using any number ofnetwork protocols (e.g., TCP/IP). Networks 101 may be connected tovarious gateways and routers, connecting various machines to oneanother, represented, e.g., by sync server 105, end user computers 103,mobile phones 102, and computer servers 106-109. In some embodiments,end user computers 103 may not be capable of receiving SMS textmessages, whereas mobile phones 102 are capable of receiving SMS textmessages. Also shown in infrastructure 100 is a cellular network 101 foruse with mobile communication devices. As is known in the art, mobilecellular networks support mobile phones and many other types of devices(e.g., tablet computers not shown). Mobile devices in the infrastructure100 are illustrated as mobile phone 102. Sync server 105, in connectionwith database(s) 104, may serve as the central “brains” and datarepository, respectively, for the multi-protocol, multi-formatcommunication composition and inbox feed system to be described herein.In the server-entry point network architecture infrastructure 100 ofFIG. 1A, centralized sync server 105 may be responsible for querying andobtaining all the messages from the various communication sources forindividual users of the system and keeping the multi-protocol,multi-format inbox feed for a particular user of the system synchronizedwith the data on the various third party communication servers that thesystem is in communication with. Database(s) 104 may be used to storelocal copies of messages sent and received by users of the system, aswell as individual documents associated with a particular user, whichmay or may not also be associated with particular communications of theusers. As such, the database portion allotted to a particular user willcontain a record of all communications in any form to and from the user.

Server 106 in the server-entry point network architecture infrastructure100 of FIG. 1A represents a third party email server (e.g., a GOOGLE® orYAHOO!® email server). (GOOGLE is a registered service mark of GoogleInc. YAHOO! is a registered service mark of Yahoo! Inc.) Third partyemail server 106 may be periodically pinged by sync server 105 todetermine whether particular users of the multi-protocol, multi-formatcommunication composition and inbox feed system described herein havereceived any new email messages via the particular third-party emailservices. Server 107 represents a represents a third party instantmessage server (e.g., a YAHOO!® Messenger or AOL® Instant Messagingserver). (AOL is a registered service mark of AOL Inc.) Third partyinstant messaging server 107 may also be periodically pinged by syncserver 105 to determine whether particular users of the multi-protocol,multi-format communication composition and inbox feed system describedherein have received any new instant messages via the particularthird-party instant messaging services. Similarly, server 108 representsa third party social network server (e.g., a FACEBOOK® or TWITTER®server). (FACEBOOK is a registered trademark of Facebook, Inc. TWITTERis a registered service mark of Twitter, Inc.) Third party socialnetwork server 108 may also be periodically pinged by sync server 105 todetermine whether particular users of the multi-protocol, multi-formatcommunication composition and inbox feed system described herein havereceived any new social network messages via the particular third-partysocial network services. It is to be understood that, in a “push-based”system, third party servers may push notifications to sync server 105directly, thus eliminating the need for sync server 105 to periodicallyping the third party servers. Finally, server 109 represents a cellularservice provider's server. Such servers may be used to manage thesending and receiving of messages (e.g., email or SMS text messages) tousers of mobile devices on the provider's cellular network. Cellularservice provider servers may also be used: 1) to provide geo-fencing forlocation and movement determination; 2) for data transference; and/or 3)for live telephony (i.e., actually answering and making phone calls witha user's client device). In situations where two ‘on-network’ users arecommunicating with one another via the multi-protocol, multi-formatcommunication system itself, such communications may occur entirely viasync server 105, and third party servers 106-109 may not need to becontacted.

Referring now to FIG. 1B, a client-entry point network architectureinfrastructure 150 is shown schematically. Similar to infrastructure 100shown in FIG. 1A, infrastructure 150 contains computer networks 101.Computer networks 101 may again include many different types of computernetworks available today, such as the Internet, a corporate network, ora Local Area Network (LAN). However, unlike the server-centricinfrastructure 100 shown in FIG. 1A, infrastructure 150 is aclient-centric architecture. Thus, individual client devices, such asend user computers 103 and mobile phones 102 may be used to query thevarious third party computer servers 106-109 to retrieve the variousthird party email, IM, social network, and other messages for the userof the client device. Such a system has the benefit that there may beless delay in receiving messages than in a system where a central serveris responsible for authorizing and pulling communications for many userssimultaneously. Also, a client-entry point system may place less storageand processing responsibilities on the central multi-protocol,multi-format communication composition and inbox feed system's servercomputers since the various tasks may be distributed over a large numberof client devices. Further, a client-entry point system may lend itselfwell to a true, “zero knowledge” privacy enforcement scheme. Ininfrastructure 150, the client devices may also be connected via thenetwork to the central sync server 105 and database 104. For example,central sync server 105 and database 104 may be used by the clientdevices to reduce the amount of storage space needed on-board the clientdevices to store communications-related content and/or to keep all of auser's devices synchronized with the latest communication-relatedinformation and content related to the user. It is to be understoodthat, in a “push-based” system, third party servers may pushnotifications to end user computers 102 and mobile phones 103 directly,thus eliminating the need for these devices to periodically ping thethird party servers.

Referring now to FIG. 2A, an example processing device 200 for use inthe communication systems described herein according to one embodimentis illustrated in block diagram form. Processing device 200 may servein, e.g., a mobile phone 102, end user computer 103, sync server 105, ora server computer 106-109. Example processing device 200 comprises asystem unit 205 which may be optionally connected to an input device 230(e.g., keyboard, mouse, touch screen, etc.) and display 235. A programstorage device (PSD) 240 (sometimes referred to as a hard disk, flashmemory, or non-transitory computer readable medium) is included with thesystem unit 205. Also included with system unit 205 may be a networkinterface 220 for communication via a network (either cellular orcomputer) with other mobile and/or embedded devices (not shown). Networkinterface 220 may be included within system unit 205 or be external tosystem unit 205. In either case, system unit 205 will be communicativelycoupled to network interface 220. Program storage device 240 representsany form of non-volatile storage including, but not limited to, allforms of optical and magnetic memory, including solid-state storageelements, including removable media, and may be included within systemunit 205 or be external to system unit 205. Program storage device 240may be used for storage of software to control system unit 205, data foruse by the processing device 200, or both.

System unit 205 may be programmed to perform methods in accordance withthis disclosure. System unit 205 comprises one or more processing units,input-output (I/O) bus 225 and memory 215. Access to memory 215 can beaccomplished using the communication bus 225. Processing unit 210 mayinclude any programmable controller device including, for example, amainframe processor, a mobile phone processor, or, as examples, one ormore members of the INTEL® ATOM™, INTEL® XEON™, and INTEL® CORE™processor families from Intel Corporation and the Cortex and ARMprocessor families from ARM. (INTEL, INTEL ATOM, XEON, and CORE aretrademarks of the Intel Corporation. CORTEX is a registered trademark ofthe ARM Limited Corporation. ARM is a registered trademark of the ARMLimited Company). Memory 215 may include one or more memory modules andcomprise random access memory (RAM), read only memory (ROM),programmable read only memory (PROM), programmable read-write memory,and solid-state memory. As also shown in FIG. 2A, system unit 205 mayalso include one or more positional sensors 245, which may comprise anaccelerometer, gyrometer, global positioning system (GPS) device, or thelike, and which may be used to track the movement of user clientdevices.

Referring now to FIG. 2B, a processing unit core 210 is illustrated infurther detail, according to one embodiment. Processing unit core 210may be the core for any type of processor, such as a micro-processor, anembedded processor, a digital signal processor (DSP), a networkprocessor, or other device to execute code. Although only one processingunit core 210 is illustrated in FIG. 2B, a processing element mayalternatively include more than one of the processing unit core 210illustrated in FIG. 2B. Processing unit core 210 may be asingle-threaded core or, for at least one embodiment, the processingunit core 210 may be multithreaded, in that, it may include more thanone hardware thread context (or “logical processor”) per core.

FIG. 2B also illustrates a memory 215 coupled to the processing unitcore 210. The memory 215 may be any of a wide variety of memories(including various layers of memory hierarchy), as are known orotherwise available to those of skill in the art. The memory 215 mayinclude one or more code instruction(s) 250 to be executed by theprocessing unit core 210. The processing unit core 210 follows a programsequence of instructions indicated by the code 250. Each instructionenters a front end portion 260 and is processed by one or more decoders270. The decoder may generate as its output a micro operation such as afixed width micro operation in a predefined format, or may generateother instructions, microinstructions, or control signals which reflectthe original code instruction. The front end 260 may also includeregister renaming logic 262 and scheduling logic 264, which generallyallocate resources and queue the operation corresponding to the convertinstruction for execution.

The processing unit core 210 is shown including execution logic 280having a set of execution units 285-1 through 285-N. Some embodimentsmay include a number of execution units dedicated to specific functionsor sets of functions. Other embodiments may include only one executionunit or one execution unit that can perform a particular function. Theexecution logic 280 performs the operations specified by codeinstructions.

After completion of execution of the operations specified by the codeinstructions, back end logic 290 retires the instructions of the code250. In one embodiment, the processing unit core 210 allows out of orderexecution but requires in order retirement of instructions. Retirementlogic 295 may take a variety of forms as known to those of skill in theart (e.g., re-order buffers or the like). In this manner, the processingunit core 210 is transformed during execution of the code 250, at leastin terms of the output generated by the decoder, the hardware registersand tables utilized by the register renaming logic 262, and anyregisters (not shown) modified by the execution logic 280.

Although not illustrated in FIG. 2B, a processing element may includeother elements on chip with the processing unit core 210. For example, aprocessing element may include memory control logic along with theprocessing unit core 210. The processing element may include I/O controllogic and/or may include I/O control logic integrated with memorycontrol logic. The processing element may also include one or morecaches.

Multi-Protocol, Multi-Format Inbox Feed

FIG. 3A shows an example of a multi-protocol, people-centric,multi-format inbox feed 300, according to one or more disclosedembodiments. The inbox feed 300 shown in FIG. 3A may, e.g., be displayedon the display of a mobile phone, laptop computer, or other computingdevice. In certain embodiments, elements of inbox feed 300 may beinteracted with by a user utilizing a touchscreen interface or any othersuitable input interface.

As is shown across the top row of the interface 302, the multi-format,multi-protocol messages received by a user of the system may be groupedby format (e.g., Email, IM/SMS, Video, Voice, etc.), or all formats maybe combined together into a single, unified inbox feed, as is shown inFIG. 3A. Row 304 in the example of FIG. 3A represents the first“people-centric” message row in the user's unified inbox feed. As shownin FIG. 3A, the pictorial icon and name of the sender whose messages arelisted in row 304 appear at the beginning of the row. The pictorial iconand sender name indicate to the user of the system that all messagesthat have been aggregated in row 304 are from exemplary user ‘EmmaPoter.’ Note that any indication of sender may be used. Also present inrow 304 are several graphical icons 306 that represent links to messagesof different types that have been received from Emma Poter. For example,Emma Poter has sent the particular user whose inbox feed is shown inFIG. 3A two email messages, one instant message, five video messages,and one voice message. The user interface may utilize icons, as is shownin FIG. 3A, or it may use any other suitable form of indication, such astext, grids, charts, or any other form of personalized identification.The types of messages/communication used in the inbox feed may beselected or personalized, as well. The timestamp (e.g., 1:47 pm in row304) may be used to indicate the time at which the mostrecently-received message has been received from a particular sender.

Moving down to row 308 of inbox feed 300, messages from a second user,Peter Ehrmanntraut, have also been aggregated into a single row of thefeed. As is displayed on the right hand side of row 308 is reveal arrow310. Selection of reveal arrow 310 may provide additional options to theuser such as to reply, delay reply/delay send, forward, return a call,favorite, archive, or delete certain message from a particular sender.Further, the reveal action may conveniently keep the user on the samescreen and allows for quick visual filtering of messages. Gestures andicon features may help the user with the decision-making processregarding the choice to reply, delay replying (including the timedelaying of response across multiple protocols), delete, mark as spam,see a full message, translate, read, or flag a message as being unread.With respect to the “delay reply/delay send” option, the multi-protocol,multi-format communication system may determine, based on the determinedoutgoing message format and protocol, that a particular communication ina particular format should be delayed before being sent to therecipient. For example, a video or voice message may not be appropriateto send at midnight, and so the system may delay sending the messageuntil such time as the recipient is more likely to be awake, e.g., 9:00am. On the other hand, the outgoing message is in text format and beingdelivered via the SMS protocol, sending the message at midnight may bemore socially-appropriate. Delay reply/delay send may also take intoaccount the time zone of the recipient and choose a moresocially-appropriate delivery time for a message based on therecipient's local time.

Finally, moving down to row 312, the ‘grayed-out’ characteristic of therow may be used to indicate that there are no remaining unread/unopenedmessages of any format or protocol type remaining from a particularsender. Alternately, each message type may be individually grayed out,indicating that there are no new messages of a particular type. It is tobe understood that the use of a grayed out row is merely exemplary, andthat any number of visual indicators may be used to inform the user ofthe device that no unread messages remain.

As may now be appreciated, the multi-protocol, people-centric,multi-format inbox feed 300 of FIG. 3A may provide various potentialbenefits to users of such a system, including: presenting email, text,voice, video, and social messages all grouped/categorized by contact(i.e., ‘people-centric,’ and not subject-people-centric,subject-centric, or format-centric); providing several potentialfiltering options to allow for traditional sorting of communications(e.g., an ‘email format’ view for displaying only emails); anddisplaying such information in a screen-optimized feed format.Importantly, centralization of messages by contact may be employed tobetter help users manage the volume of incoming messages in any formatand to save precious screen space on mobile devices (e.g., such adisplay has empirically been found to be up to six to seven times moreefficient that a traditional inbox format). Further, such an inbox feedmakes it easier for a user to delete unwanted messages or groups ofmessages (e.g., spam or graymail). The order of appearance in the inboxfeed may be customized as well. The inbox feed may default to showingthe most recent messages at the top of the feed. Alternatively, theinbox feed may be configured to bring messages from certain identified“VIPs” to the top of the inbox feed as soon as any message is receivedfrom such a VIP in any format and/or via any protocol. The inbox feedmay also alert the user, e.g., if an email, voice message, and text haveall been received in the last ten minutes from the same person—likelyindicating that the person has an urgent message for the user. The inboxfeed may also identify which companies particular senders are associatedwith and then organize the inbox feed, e.g., by grouping allcommunications from particular companies together.

In other embodiments, users may also select their preferred deliverymethod for incoming messages of all types. For example, they can chooseto receive their email messages in voice format or voice messages intext, etc.

Referring now to FIG. 3B, an example of a multi-protocol, multi-formatinbox feed for messages to and from a particular user 320 is shown,according to one or more disclosed embodiments. As is shown across thetop row of the interface 322, the messages from a particular user, inthis case ‘Peter Ehrmanntraut’ may be displayed in a singlemulti-format, multi-protocol message feed. Row 322 in the example ofFIG. 3B also presents the user with the opportunity to select theparticular sender's ‘Messages,’ ‘Profile,’ or ‘Vault’ storage, which isa document repository of files shared between the user and a particularsender (e.g., email attachments, MMS, etc.). As shown in FIG. 3B, thepictorial icon 324 and name of the sender whose messages are listed ininterface 320 appear at the top of the communications page. Also presentin interface 320 is search icon 326, which may be activated to searchacross all message formats and protocols (e.g., including voice andvideo messages) from a particular sender for a particular search term(s)or topic. Message items may also be sorted in the feed by variouscharacteristics such as time of receipt, format, or other content and/orsemantic-based ranking schemes. Moving down to the messages portion ofinterface 320, checkbox 328 represents the first email message receivedfrom user Peter Ehrmanntraut, whereas checkbox 330 represents the firstnew video message from user Peter Ehrmanntraut. Finally, grayed-outcheckbox 332 represents an aggregation of voice messages that havealready been listened to by the user.

Referring now to FIG. 3C, an example of a preview pane 340 for amulti-protocol, multi-format inbox feed for messages to and from aparticular user is shown, according to one or more disclosedembodiments. As is displayed in FIG. 3C, the message associated withcheckbox 328 has been opened to provide a more in-depth preview of theassociated email text. According to some embodiments, the recipients 342are listed out above the body 344 of the email, and a link 346 may beactivated that causes the application to retrieve the full email messagefrom either the system's sync server or third party email servers. Theinterface may also provide a number of preview quick action buttons 348to be performed on the message that is being previewed, e.g., reply,reply all, forward, delete, etc.

Referring now to FIG. 3D, an example of a document repository page 380for a particular user is shown, according to one or more disclosedembodiments. Row 382 in the example of FIG. 3D presents the user withthe opportunity to select the particular sender's ‘Vault’ page, which isa document repository of files shared between user and the particularsender (e.g., email attachments, MMS, etc.). As with the messagesinterface, a searching functionality 384 may be provided, which searchesthe documents associated with the particular user's Vault. A user'sVault may include multimedia files 386, such as photos, in addition toother files 388, such as word processing and presentation documents.

Multi-Protocol, Multi-Format Communication Composition User Interface

Referring now to FIG. 3E, an example of a multi-protocol, multi-formatcommunication composition user interface 390 is shown, according to oneor more disclosed embodiments. The top row of interface 390 in theexample of FIG. 3E presents the user with several options related to thecomposition of a given communication. For instance, icon 392 may providethe user with the ability to geo-tag his or her location onto themessage being sent. Icon 393 may be used to indicate that a message hasa special status, such as a ‘poll question’ or other ‘request forrecommendation’ with a response requested by the sender. Such specialstatus messages may optionally be sent to ‘tiers’ of contacts (e.g.,first-tier relationship, second-tier relationships, etc.) or even thegeneral public, as opposed to particular contacts. Icon 394 may be usedto attach one or more file attachments to the message being composed,button 399 may be used to cancel the message being composed, and button395 may be used to send off the message to the one or more recipientsspecified in the “To:” field 391.

Message box 396 may be used by the user to enter his or her message anydesired communications format or protocol that the system is capable ofhandling. For example, a text message may be entered by activating icon397 and using an on-screen keyboard or the like. Alternately, an audiomessage or a video message may be recorded by activating the other iconsacross the top row of message box 396. Once the message has beencomposed in the desired format, the user may utilize the row of icons399 across the bottom of message box 396 to select the desired deliveryprotocol for the outgoing communication. As shown in FIG. 3E, thoseprotocols may include, e.g., email, SMS/MMS/IM, or Optimal. As may beunderstood, the selection of desired delivery protocol may necessitate aconversion of the format of the composed message. For example, if amessage is entered in audio format, but is to be sent out in a textformat, such as via the SMS protocol, the audio from the message wouldbe digitized, analyzed, and converted to text format before sending viaSMS (i.e., a speech-to-text conversion). Likewise, if a message isentered in textual format, but is to be sent in voice format, the textfrom the message will need to be run through a text-to-speech conversionprogram so that an audio recording of the entered text may be sent tothe desired recipients in the selected voice format via the appropriateprotocol, e.g., via an email message.

The selection of the “Optimal” delivery option may have several possibleimplementations. The selection of output message format and protocol maybe based on, e.g., the format of the incoming communication, thepreferred format or protocol of the recipient and/or sender of thecommunication (e.g., if the recipient is an ‘on-network’ user who hasset up a user profile specifying preferred communications formats and/orprotocols), an optimal format or protocol for a given communicationsession/message (e.g., if the recipient is in an area with a poorservice signal, lower bit-rate communication formats, such as text, maybe favored over higher bit-rate communications formats, such as video orvoice), and/or economic considerations of format/protocol choice to therecipient and/or sender (e.g., if SMS messages would charge therecipient an additional fee from his or her provider, other protocols,such as email, may be chosen instead).

Other considerations may also go into the determination of an optimaldelivery option, such as analysis of recent communication volume,analysis of past communication patterns with a particular recipient,analysis of recipient calendar entries, and/or geo-position analysis.Other embodiments of the system may employ a ‘content-based’determination of delivery format and/or protocol. For example, if anoutgoing message is recorded as a video message, SMS may bede-prioritized as a sending protocol, given that text is not an idealprotocol for transmitting video content. Further, natural languageprocessing (NLP) techniques may be employed to determine the overallnature of the message (e.g., a condolence note) and, thereby, assess anappropriate delivery format and/or protocol. For example, the system maydetermine that a condolence note should not be sent via SMS, but rathertranslated into email or converted into a voice message. Thus, thetechniques disclosed herein allow communications systems to become‘message-centric,’ as opposed to ‘protocol-first,’ eventually allowingconsideration of message protocol to fall away entirely for the senderof the communication.

Another beneficial aspect of the multi-protocol, multi-formatcommunication composition system described herein is the ability toallow the user to send one message to the same recipient in multipleformats and/or via multiple protocols at the same time (or with certainformats/protocols time delayed). Likewise, the multi-protocol,multi-format communication composition system also allows the user theability to send one message to multiple recipients in multiple formatsand/or via multiple protocols. The choice of format/protocol for theoutgoing message may be made by either the system (i.e.,programmatically) or by the user, e.g., by selecting the desiredformats/protocols via the user interface of the multi-protocol,multi-format communication composition system.

FIG. 4 shows a flowchart 400 of one embodiment of a method forpopulating a multi-protocol, people-centric, multi-format inbox feed,according to one or more disclosed embodiments. First, the system mayprompt the user to input his or her credentials so that he or she may beauthenticated and authorized (Step 405). Next, the sync server 105and/or third-party servers 106-109 may verify and validate the user'scredentials as being authorized to receive communications associatedwith a particular account(s) tied to a particular messaging service(s)(Step 410). Next, the user's credentials are encrypted and stored at thesync server 105 so that the user's messages may continue to be retrievedby the system (Step 415). Once the user's credentials have been verifiedand stored, the system may attempt to synchronize the user'smulti-protocol, people-centric, multi-format unified messaging inboxfeed with the various external communication servers hosting the user'smessages from the various third-party messaging services, e.g., by usingone or more third-party credentials of the first user stored at the syncserver (Step 420). Next, the system may receive a query from aparticular user's client device (e.g., to pull new communicationsdirected to the user) and determine that the client device has access toperform the query (Step 425). Assuming the client device has access, thequery will be executed, and the results will be retrieved and optionallyreformatted, ranked, etc., according to the user's and/or system'spreferences (Step 430). One example of a formatted and sorted queryresult set is shown in the exemplary user interface of FIG. 3A.

When the user desires to transmit a user-generated message, e.g., viathe exemplary user interface of FIG. 3E, the process may resume at Step435 by the client device transmitting the user-generated message eitherto the system's sync server or directly to the third-partycommunications servers. At that point, it may again be verified that theclient device has access to send the message(s) (Step 440). If theclient device does not have access, the user will again be prompted toenter his or her authentication credentials (Step 445). Once properauthentication has been established, the transmission of theuser-generated message may be completed via the designated protocol(s).The nature and type of the protocols may be determined, e.g., inaccordance with one or more of the various rules and preferencesdiscussed above with reference to FIG. 3E.

User Interface-Driven Search Query Generation

FIG. 5 shows a flowchart 500 of one embodiment of a method forprocessing a user interface-driven query, according to one or moredisclosed embodiments. First, a client device may send a query to acentral communications system server, such as sync server 105, based onthe status of the currently-displayed user interface (UI) on the clientdevice (Step 505). For example, with respect to the user interface 300shown in FIG. 3A, the selection of a row in the currently-displayed UIfor sender ‘Emma Poter’ could be associated with one or moresystem-defined “tags” that would be used by the system to generate aquery for messages from user ‘Emma Poter.’ Likewise, changing the UI tothe ‘Video’ tab in row 302 of user interface 300 would generate a queryfor only messages in a video format, etc. Next, the system may determineif there are cached results for the query that the client device iscurrently trying to send (Step 510). If there are cached results at Step510, the query may be limited to events occurring since the lastidentical query was issued by the client device (Step 515), and then thelimited query may be executed by the central communication system server(Step 520). If there are no cached results at Step 510, then the fullquery may simply be executed by the central communication system server(Step 520).

After some amount of time, the client device may poll the inbox feedapplication to determine whether there is a new UI displaying on theclient device (Step 525). If there is a new UI being displayed on theclient device, the process 500 may return to Step 505 so that the clientapplication may create and send a new query to the centralcommunications system server based on the currently-displayed UI. If,instead, there is not a new UI being displayed on the client device, theclient application may determine whether a given time interval, t, haspassed since the last query that was sent to the central communicationssystem server (Step 530). If the time interval, t, has not passed sincethe last time the UI was updated, the client application may simplyreturn to Step 525 and continue to poll the inbox feed application todetermine whether there is a new UI displaying on the client device. If,instead, the time interval, t, has passed since the last time the UI wasupdated, the client application may simply return to Step 505 so thatthe client application may create and send a new query to the centralcommunications system server based on the currently-displayed UI. It isto be understood that the exemplary method shown in flowchart 500 mayalso be achieved by use of a “push-based” system, too, wherein the inboxfeed application may push information to the client device periodicallywithout the need for the client device to poll the server.

FIG. 6 shows a flowchart 600 of one embodiment of a method for creatinga multi-protocol, multi-format communication transmission, according toone or more disclosed embodiments. First, the user interface of theclient application may present the user with the capability to selectany number of contacts from any source type (Step 605). Next, the userinterface of the client application may present the user with thecapability to select any composition format (Step 610). Next, the userinterface of the client application may present the user with thecapability to tag any desired attachments and/or geo-local data with theoutgoing message (Step 615). Next, the user interface of the clientapplication may present the user with the capability to select thedesired communication delivery protocol (Step 620). Next, the userinterface of the client application may present the user with thecapability to reply/forward a given message in symmetric default format(i.e., the same format that the message was received in) or analternative format (Step 625). Finally, the system may deliver themessage to the selected recipient(s) in the selected/determinedformat(s). As described above in reference to FIG. 3E, the outgoingmessage format may be sent with or without delay, may have multipledegrees of accessibility, may be based on user preference, protocoloptimization, and/or system defaults.

Optimal Delivery Selection

As mentioned previously, the Optimal delivery option is the selection ofoutput message format and protocol based on the format of the incomingcommunication, the preferred format or protocol of the recipient and/orsender of the communication, an optimal format or protocol for a givencommunication session/message, and/or economic considerations offormat/protocol choice to the recipient and/or sender. Many factors,preferences and historic usage comprise the input into theimplementation that effectuates this option. The Optimal delivery optionmay be selected by the Sender's client device or by a centralcommunication server running the Optimal Decision Engine.

The Optimal Decision Engine does not require that all ‘Participants’(sender(s) & receiver(s)) in any given message or conversation beregistered users, or “on-network,” of the multi-format communicationnetwork described herein in order to provide the initial registeredSender (also known as the ‘Composer’) with an intelligent prediction asto the optimal delivery path for each recipient(s). The Optimal DecisionEngine could use information such as calendar information showingwhether the recipient is in a meeting, recipient position or motioninformation (e.g., whether the recipient is driving, walking, sleeping,etc.), or historic communication patterns as a way to determine formator protocol.

In cases where a message or conversation contains more than one intendedrecipients, and the Sender activates the Optimal delivery option, theOptimal Decision Engine may be instantiated to evaluate the bestdelivery method of the given message for each recipient as individualparties as well as in a group-based relationship context. For example,based on historical patterns of communication, it can be determined bythe Optimal Decision Engine that Sender frequently communications withrecipients A, B, and C, each using personal email addresses. Inaddition, the Optimal Decision Engine can leverage similar historicaltransaction patterns to assess that Sender frequently using anotherprotocol/address when communicating with recipients A, B, and C as asingle group. Therefore, using this first method (based primarily onhistoric data patterns), the Optimal Decision Engine is able to provideintelligent, context-aware suggestions on preferred message deliverymethod with only Sender as a registered user of the multi-format,multi-protocol communication network.

When one Sender and at least one recipient are registered users, or“on-network,” of the multi-format, multi-protocol communicationsnetwork, then, in addition to using traditional formats or protocols,messages sent through the multi-format, multi-protocol communicationcomposition system described herein may also reach recipients via anestablished ‘on-network’ format or protocol.

FIG. 7 shows a block diagram 700 of one embodiment of a UniversalMessage Object (UMO), according to one or more disclosed embodiments.The block diagram 700 describes the relationship between variouscomponents of data required to make the optimal delivery optionpossible. It should be appreciated that the UMO facilitates not only thecommunication between ‘on-network’ and ‘off-network’ users, but alsofacilitates the backflow of updating relevant conversation historiesbased on the message format and communication protocol utilized.

Participant 710 objects represent an “on-network” or “off-network”users. Participant 710 objects correspond to any people identified inthe traditional email format fields of “To,” “From,” “Cc,” and “Bcc.”However, the Participant 710 objects are not limited to this, as aParticipant 710 may be any user engaged in the conversation, and isrelational to the service being used as the underlying communicationprotocol.

Service Identifier 705 object represents the service utilized by asingle Participant 710 object in the delivery of a format over acommunication protocol. For each “To”, “From,” “Cc,” and “Bcc”associated with a message, there is a Participant 705 object containinga Service Identifier 705 indicating which service was used as theunderlying format and communication protocol. The Service Identifierinclude data related to the delivery of the message, including the typeof the service, and the address. In the case of an SMS text message, aService Identifier 705 object would have the type of “sms” and theaddress would be respective telephone number. The Service Identifier 705object implies a format and communication protocol unique to thatindicated service.

Message Unique 715 is the representation format and communicationprotocol specific format for a message. For every message sent using theOptimal delivery method, one or more Message Unique 715 objects may beinstantiated. Message Unique 715 objects contain the format andcommunication protocol specific data gathered during the Optimaldelivery process. For example, time stamps of sent and received, basedon the communication protocol are stored in the object. Additionally, ininstances where the format and communication protocol are limited insome fundamental way, e.g. TWITTER® messages limited to 140 charactersand SMS text message 160 character limit, it may be necessary to sendmultiple messages across these communication protocols to fully conveythe Sender's intended message. For this purpose, multiple Message Unique715 objects would be instantiated to track the transmitted content.

The Message Common 720 object is the message that an “on-network” userviews in their inbox feed. For every user message sent, there are commoncomponents present in all formats and communication protocols. Forefficiency, these common components are extracted and contained in oneobject. Because of this efficiency, there is one Message Common 720object for every message sent by the Sender. For example, the MessageCommon 720 object may store the body of the message, as well as the timesent at the moment the Sender selects ‘send,’ not the ‘sent time’ asreported by the underlying communication protocol. This has theadvantage of presenting one view to the Sender and recipient(s), whileresolving minor discrepancies from the underlying communicationprotocol.

The Message Source 725 object is a representation of the Message Unique715 object in a Javascript object notation (JSON) format. The MessageSource 725 object has a one to one relationship with the Message Unique715 object.

Message Group 730 object is a representative identifier that coordinatesa Message Common 720 object. The purpose of a Message Group 730 objectis to enable multi-protocol communication and establish a relationshipbetween those messages. There is a one to one relationship between theMessage Group 730 object and the Message Common 720 object.

As multiple multi-protocol communication messages are being representedin this data model, it enables the system to truly facilitate amulti-protocol multi-format communication system. The system tracks eachconversation by the Message Group 730 object relating to the MessageCommon 720 and then all the individual Message Unique 715 objects thatrelate to the Message Common 720. By tracking all the Message Unique 715objects with the Message Group 730 objects, it is possible to build across-protocol communication history. This history includes allcommunications from any given Participant 710 object across multipleMessage Unique 715 objects with different Service Identifier 705objects. Stated another way, the UMO can track and correlate historiccommunications across multiple protocols and formats utilizing theMessage Group 730 objects, in conjunction with the other UMO objects.With this the UMO can track frequency of communication method, time ofday of communication, historic rates of response, and patterns of groupcommunication.

To enable the optimal delivery option, the UMO may be converted into anextensible format to allow for the representation, and subsequentconversion, of the dissimilar components. Javascript object notation(JSON) is a format that allows for a flexible field enumeration, as wellas parsers and database conversion tools. In this embodiment, fieldsfrom the multiple objects of the Universal Message Object can be relatedand combined to create a unified view of the UMO and its components.Below, code Example 1 is demonstrative of a UMO implemented in JSON.

Example 1

{ “id”: “545436576657”, “body”: { “text”: “Hey guys, we are modifyingcompany policy regarding email messages tomorrow, so please be on thelookout for a followup”, “html”: “<p> Hey guys, we are modifying companypolicy regarding email messages tomorrow<table><row> , so please be onthe lookout for </row><row> a followup</row></table> </p>” },“createdOn”: “2012-10-09T20:30:40.678Z”, “date”:“2012-10-09T20:30:40.678+00:00”, “headers”: { “x-mailer”:“coolcompany.com” “participants”: { “from”: { “id”: “63423324”, “name”:“Bob Jones”, “address”: “bob.jones@coolcompany.com”, “type”: “email” },“to”: { “id”: “1139178368”, “name”: “Sam Smith”, “address”: “5553625143”“type”: “sms” } } }

The conversion of any incoming messages to a common format allows formore efficient extraction of fields used in by any predicative datamodels. Put another way, the common format is an intermediary format formore efficient processing inside the multi-format, multi-protocolcommunication system.

FIG. 8 shows a sequence diagram depicting one embodiment of a method forupdating a system with data points used to determine optimal deliveryselection, according to one or more disclosed embodiments.

User A utilizes client 1 805. Client 1 805 communicates with a server810. The communication synchronizes optimal data transmission methodbetween the server 810 and multiple clients in the context of a user. Inthis embodiment, user A utilizes only client 1 805. In anotherembodiment, user A may use multiple clients. At given calculationintervals 725, the server calculates an optimal delivery format 815-1through 815-N for user generated messages that are partially dependenton time. Put another way, time is an input into a function thatgenerates the optimal delivery selection. The optimal delivery selectionis the resultant output of a predictive time-based data model. Thepredictive time-based data model analyzes historic patterns ofcommunication of the user and recipients. These patterns include thecontext and frequency of the messaging. The context of the messages mayinclude geo locational information, time of day, and content of themessage itself. The predictive time-based data model utilizes thesepatterns to determine an intersection of the patterns of both the userand the recipients, to determine the optimal delivery option for both.The patterns based on content, may be defined to apply only in terms ofone contextual element, or a combination of multiple elements. As timevaries, so does the optimal delivery selection. The calculationintervals 825 for client 1 825 are relatively short. However, bothsynchronization intervals are greater than or equal to a minimum timeinterval 820.

When user A utilizes client 1 805 in sending a message to a recipient,the message is passed on to the server 810. Client 1 805 and the server810 participate in an exchange 830, 835. In this embodiment, theexchange 830, 835 is synchronous, however in other embodiments, it mayasynchronous. The exchange 830, 835 involves the delivery of the messagefrom client 1 805 to the server 810, the server 810 calculating anoptimal delivery format 815-1 through 815-N based on the content andcontext of the received message, and providing a synchronized responseindicating a new optimal delivery selection. In this embodiment, thefrequency of the client 1 and server exchange 830, 835 shape thecalculation intervals 825 for client 1 805. As more messages arereceived at the server 810 from client 1 805, the calculation intervals825 for client 1 805 become more frequent, providing a larger data setto generate a more precise optimal delivery selection.

FIG. 9 is a flowchart of one embodiment of a method for determining anoptimal protocol for transmitting a message to a recipient. Thisflowchart is one embodiment of the exchange 830, 835 of FIG. 8. Thesteps depicted here may, e.g., take place after the system has receiveda message from the Sender to one or more desired recipients. First, thesystem receives communication history for the Sender (Step 905). Forexample, communication history may include user preferences that may bepreviously defined rules based on how the Sender likes to receive onlyemails after 11 pm. Communication history includes how the Sendercommunicated last with the intended recipient, or when how the Sendercommunicated with the recipient at the same time over a previous timeperiod.

The system then evaluates if the recipient is “on-network” (Step 910).Recipient(s) on network, like the Sender, have previously defined rulesas well as stored historical context. If the recipient(s) is“on-network” their communication history is also retrieved (Step 915) ina similar manner to that of the Sender.

The flows then converge in the parsing of the message content using NLP(Step 920) techniques. This includes extracting keywords. The NLP may betargeting keyword generation that is indicative of past communication,or context that may be used to appropriately determine the optimalmechanism for delivery.

The system then provides the NLP generated keywords, all availablecommunication history, including all available preference data to theOptimal Decision Engine (Step 925). In this embodiment, the OptimalDecision Engine may utilize a predictive time-based data model, builtbased on the historical context and the parsed message itself.Factorization machine, support vector machines, or other machinelearning techniques may be utilized to effectuate the predictivetime-based data model.

After the Optimal Decision Engine determines an appropriate deliveryprotocol based on the input factors, the system formats the message(Step 930) for delivery by the determined protocol. The formattingincludes moving the content into the body of the message and preparingit for dispatch.

After the system successfully formats the message for the specifieddelivery protocol, the preferences and communication history for theuser are updated (Step 935) in the database as an input data point laterused to predict the Sender's method of response. Additional data may bestored in the database including frequency of the Sender's messages, thetime of day of the messages, the rates of response to messages, andpatterns of group communication. Finally the system sends the message(Step 940). Alternatively, the system may update the preferences andhistory for the Sender and the recipient(s) (Step 935) after the sendingof the message, to verify the actual transmission of the message.

Examples

The following examples pertain to further embodiments.

Example 1 is a non-transitory computer readable medium comprisingcomputer instructions stored thereon to cause one or more processingunits to receive a cross-protocol communication history for a user;receive a message from the user addressed to one or more desiredrecipients; determine, based on the cross-protocol communication historyfor the user, an optimal protocol for delivery of the message for eachof the one or more desired recipients, wherein the instructions todetermine further comprise instructions to use a predictive time-baseddata model; transform the message into the respective optimal deliveryprotocol for each of the one or more desired recipients; transmit themessage in the respective optimal delivery protocol to each of the oneor more desired recipients; and update the cross-protocol communicationhistory for the user and the predictive time-based data model based, atleast in part, on the transmission of the message.

Example 2 includes the subject matter of example 1, wherein thecross-protocol communication history for the user comprises at least oneof the following: a frequency of communication protocol usage; a time ofday of communication; a historic rate of response; and a pattern ofgroup communications.

Example 3 includes the subject matter of example 1, wherein theinstructions to determine an optimal protocol for delivery compriseinstructions to analyze historic patterns of communication of the userbased on context; analyze historic patterns of communication of the oneor more desired recipients based on context; and determine theintersection of the historic patterns of the user and historic patternsof the one or more desired recipients.

Example 4 includes the subject matter of example 3, wherein the contextcomprises at least one of the following: geo-locational information,time of day, and content of the message.

Example 5 includes the subject matter of example 1, wherein theinstructions to determine are executed at a set interval of time based,at least in part, on the predictive time-based data model.

Example 6 includes the subject matter of example 1, wherein the optimalprotocol for delivery of the message for at least one of the one or moredesired recipients comprises at least one of the following protocols:Short Message Service (SMS); email; instant messaging; and voice mail.

Example 7 includes the subject matter for example 1, wherein thepredictive time-based data model comprises a factorization machine.

Example 8 is an apparatus comprising a memory; and one or moreprocessing units, communicatively coupled to the memory wherein thememory stores instructions to configure the one or more processing unitsto: receive a cross protocol communication history for a user; receive amessage from the user addressed to one or more desired recipients;determine, based on the cross platform communication history for theuser, an optimal protocol for delivery of the message for each of theone or more desired recipients, wherein the instructions to determinefurther comprise instructions to use a predictive time-based data model;transform the message into the respective optimal delivery protocol foreach of the one or more desired recipients; transmit the message in therespective optimal delivery protocol to each of the one or more desiredrecipients; and update the cross protocol communication history for theuser and the predictive time-based data model based, at least in part,on the transmission of the message.

Example 9 includes the subject matter of example 8, wherein the crossprotocol communication history comprises frequency of communicationmethod, time of day of communication, historic rates of response, andpatterns of group communication.

Example 10 includes the subject matter of example 8, wherein theinstructions to determine comprises: analyze historic patterns ofcommunication of the user based on context; analyze historic patterns ofcommunication of the one or more desired recipients based on context;and determine the intersection of the historic patterns of the user, andhistoric patterns of the one or more desired recipients.

Example 11 includes the subject matter of example 10, wherein thecontext comprises at least one of the following: geo-locationalinformation, time of day, and content of the message.

Example 12 includes the subject matter of example 8, wherein theinstructions to determine are executed at a set interval of time based,at least in part, on the predictive time-based data model.

Example 13 includes the subject matter of example 8, wherein the optimalprotocol for delivery of the message for at least one of the one or moredesired recipients comprises at least one of the following protocols:Short Message Service (SMS); email; instant messaging; and voice mail.

Example 14 is a computer-implemented method for selecting optimaltransmission of digital messages comprising: receiving a cross protocolcommunication history for a user; receiving a message from the useraddressed to one or more desired recipients; determining, based on thecross-protocol communication history for the user, an optimal protocolfor delivery of the message for each of the one or more desiredrecipients, wherein the instructions to determine further compriseinstructions to use a predictive time-based data model; transforming themessage into the respective optimal delivery protocol for each of theone or more desired recipients; transmitting the message in therespective optimal delivery digital protocol to each of the one or moredesired recipients; and updating the cross protocol communicationhistory for the user and the predictive time-based model based, at leastin part, on the transmission of the message.

Example 15 includes the subject matter of example 14, wherein the crossprotocol communication history comprises frequency of communicationmethod, time of day of communication, historic rates of response, andpatterns of group communication.

Example 16 includes the subject matter of example 14, whereindetermining comprises: analyzing historic patterns of communication ofthe user based on context; analyzing historic patterns of communicationof the one or more desired recipients based on context; and determiningthe intersection of the historic patterns of the user, and historicpatterns of the one or more desired recipients.

Example 17 includes the subject matter of example 16, wherein thecontext comprises at least one of the following: geo-locationalinformation, time of day, and content of the message.

Example 18 includes the subject matter of example 14, wherein thedetermining is executed at a set interval of time based, at least inpart, on the predictive time-based data model.

Example 19 includes the subject matter of example 14, wherein theoptimal protocol for delivery of the message for at least one of the oneor more desired recipients comprises at least one of the followingprotocols: Short Message Service (SMS); email; instant messaging; andvoice mail.

Example 20 includes the subject matter of example 14, wherein thepredictive time-based data model comprises a factorization machine.

In the foregoing description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the disclosed embodiments. It will be apparent,however, to one skilled in the art that the disclosed embodiments may bepracticed without these specific details. Reference in the specificationto “one embodiment” or to “an embodiment” means that a particularfeature, structure, or characteristic described in connection with theembodiments is included in at least one disclosed embodiment, andmultiple references to “one embodiment” or “an embodiment” should not beunderstood as necessarily all referring to the same embodiment.

It is also to be understood that the above description is intended to beillustrative, and not restrictive. For example, above-describedembodiments may be used in combination with each other and illustrativeprocess steps may be performed in an order different than shown. Manyother embodiments will be apparent to those of skill in the art uponreviewing the above description. The scope of the invention thereforeshould be determined with reference to the appended claims, along withthe full scope of equivalents to which such claims are entitled. In theappended claims, terms “including” and “in which” are used asplain-English equivalents of the respective terms “comprising” and“wherein.”

What is claimed is:
 1. A non-transitory computer readable mediumcomprising computer instructions stored thereon to cause one or moreprocessing units to: receive a cross-protocol communication history fora user; receive a message from the user addressed to one or more desiredrecipients; determine, based on the cross-protocol communication historyfor the user, an optimal protocol for delivery of the message for eachof the one or more desired recipients, wherein the instructions todetermine further comprise instructions to use a predictive time-baseddata model; transform the message into the respective optimal deliveryprotocol for each of the one or more desired recipients; transmit themessage in the respective optimal delivery protocol to each of the oneor more desired recipients; and update the cross-protocol communicationhistory for the user and the predictive time-based data model based, atleast in part, on the transmission of the message.
 2. The non-transitorycomputer readable medium of claim 1, wherein the cross-protocolcommunication history for the user comprises at least one of thefollowing: a frequency of communication protocol usage; a time of day ofcommunication; a historic rate of response; and a pattern of groupcommunications.
 3. The non-transitory computer readable medium of claim1, wherein the instructions to determine an optimal protocol fordelivery comprise instructions to: analyze historic patterns ofcommunication of the user based on context; analyze historic patterns ofcommunication of the one or more desired recipients based on context;and determine the intersection of the historic patterns of the user andthe historic patterns of the one or more desired recipients.
 4. Thenon-transitory computer readable medium of claim 3, wherein the contextcomprises at least one of the following: geo-locational information,time of day, and content of the message.
 5. The non-transitory computerreadable medium of claim 1, wherein the instructions to determine areexecuted at a set interval of time based, at least in part, on thepredictive time-based data model.
 6. The non-transitory computerreadable medium of claim 1, wherein the optimal protocol for delivery ofthe message for at least one of the one or more desired recipientscomprises at least one of the following protocols: Short Message Service(SMS); email; instant messaging; and voice mail.
 7. The non-transitorycomputer readable medium of claim 1, wherein the predictive time-baseddata model comprises a factorization machine.
 8. An apparatuscomprising: a memory; and one or more processing units, communicativelycoupled to the memory wherein the memory stores instructions toconfigure the one or more processing units to: receive a cross-protocolcommunication history for a user; receive a message from the useraddressed to one or more desired recipients; determine, based on thecross platform communication history for the user, an optimal protocolfor delivery of the message for each of the one or more desiredrecipients, wherein the instructions to determine further compriseinstructions to use a predictive time-based data model; transform themessage into the respective optimal delivery protocol for each of theone or more desired recipients; transmit the message in the respectiveoptimal delivery protocol to each of the one or more desired recipients;and update the cross-protocol communication history for the user and thepredictive time-based data model based, at least in part, on thetransmission of the message.
 9. The apparatus of claim 8, wherein thecross-protocol communication history comprises frequency ofcommunication method, time of day of communication, historic rates ofresponse, and patterns of group communication.
 10. The apparatus ofclaim 8, wherein the instructions to determine comprise instructions to:analyze historic patterns of communication of the user based on context;analyze historic patterns of communication of the one or more desiredrecipients based on context; and determine the intersection of thehistoric patterns of the user and the historic patterns of the one ormore desired recipients.
 11. The apparatus of claim 10, wherein thecontext comprises at least one of the following: geo-locationalinformation, time of day, and content of the message.
 12. The apparatusof claim 8, wherein the instructions to determine are executed at a setinterval of time based, at least in part, on the predictive time-baseddata model.
 13. The apparatus of claim 8, wherein the optimal protocolfor delivery of the message for at least one of the one or more desiredrecipients comprises at least one of the following protocols: ShortMessage Service (SMS); email; instant messaging; and voice mail.
 14. Acomputer-implemented method for selecting optimal transmission ofdigital messages comprising: receiving a cross-protocol communicationhistory for a user; receiving a message from the user addressed to oneor more desired recipients; determining, based on the cross-protocolcommunication history for the user, an optimal protocol for delivery ofthe message for each of the one or more desired recipients, whereindetermining further comprises using a predictive time-based data model;transforming the message into the respective optimal delivery protocolfor each of the one or more desired recipients; transmitting the messagein the respective optimal delivery digital protocol to each of the oneor more desired recipients; and updating the cross-protocolcommunication history for the user and the predictive time-based modelbased, at least in part, on the transmission of the message.
 15. Thecomputer-implemented method of claim 14, wherein the cross-protocolcommunication history comprises frequency of communication method, timeof day of communication, historic rates of response, and patterns ofgroup communication.
 16. The computer-implemented method of claim 14,wherein determining comprises: analyzing historic patterns ofcommunication of the user based on context; analyzing historic patternsof communication of the one or more desired recipients based on context;and determining the intersection of the historic patterns of the userand the historic patterns of the one or more desired recipients.
 17. Thecomputer-implemented method of claim 16, wherein the context comprisesat least one of the following: geo-locational information, time of day,and content of the message.
 18. The computer-implemented method of claim14, wherein the determining is executed at a set interval of time based,at least in part, on the predictive time-based data model.
 19. Thecomputer-implemented method of claim 14, wherein the optimal protocolfor delivery of the message for at least one of the one or more desiredrecipients comprises at least one of the following protocols: ShortMessage Service (SMS); email; instant messaging; and voice mail.
 20. Thecomputer-implemented method of claim 14, wherein the predictivetime-based data model comprises a factorization machine.